Asynchronous messaging is a widely used means of communication between loosely coupled participant systems engaged in a collaborative process such as, e.g., an electronic business process involving distributed business partners. Generally, a collaborative process is one that is characterized by a plurality (two or more) of participants collaborating through exchange of messages in order to accomplish an overall goal or result. Collaborative business processes can be conducted among participants within a single enterprise. They can also involve business partners from different enterprises. Electronic financial controlling/budgeting systems, electronic material resource planning/controlling systems, and electronic purchase/sales order systems are but examples of modern electronic business/commerce applications that may involve collaborative processes of distributed participants, or clients.
Generally, a participant system engaged in a computer-implemented collaborative process can be viewed as comprising the entirety of hardware and software components required to make up a full-fledged participant to the process. In a more specific perspective, a participant system is formed by a software system implemented and executed on a computer and providing one or more software applications capable of consuming and producing messages received from, and sent to, other participant systems. The participant system may include, or have access to, one or more databases allowing storage of various application-related data such as, e.g., financial figures, fabrication figures, stock figures, etc. The messages exchanged between the participant systems may, e.g., contain requests or reports specifying business actions. The exchange of the messages is asynchronous in that an application sending a message does not need to wait for a remote application to receive that message. Thus, there is no need for all elements of the infrastructure linking the participant systems to be available at all times.
A conventional way of specifying a collaborative process is using UML (Unified Modeling Language) state chart diagrams. A state chart diagram specifies states that can be assumed by a participant system or a sub-system thereof in the course of the collaborative process as well as state transitions of the participant system/sub-system. A sub-system of a participant system can, e.g., be a software object that forms part of a software application program. Software objects can, e.g., represent business objects in a business application. Each participant system of a collaborative process can comprise multiple software sub-systems each having unique sub-system states and sub-system state transitions. The term software sub-system as used herein is to be given the broadest and most general meaning. A software sub-system simply refers to a functional and/or logical and/or physical part or portion of the entirety of software that is present in a participant system. In particular, the term software sub-system as used herein expressly supports a concept in which the processing of data in two or more software sub-systems of the same participant system can be done, and the sub-systems' states can be updated, in one transaction.
Generally, a state transition is defined by a starting state, a target state, a triggering event and a resulting event. The starting state and the target state can be different, or be the same. In the first case, the participant system/sub-system experiences a transition from one state to another, in the second case, a transition-to-self. A triggering event can, e.g., be a message transmitted over the messaging network from another participant system. It can also be a local event unrelated to communication over the messaging network, e.g., a data input through a local user interface or by another local software application. A triggering event can even be a message that is outside the scope of the process analysis. From the sight of the process model, such external message can be triggered as unmotivated as any local event due to, e.g., user action or batch transaction. Similarly, a resulting event can include the sending of a message to another participant system and/or an event local to the respective participant system, e.g., an output of data for display on a monitor or storage in a database.
Optimally, a collaboration specification deals with every possible scenario of occurring messages, states, and state transitions of the software systems/sub-systems involved in the process. However, when developing a collaborative process it may easily happen that one or more potentially occurring scenarios are not considered and remain unspecified. If the collaboration process is implemented using a specification that is incomplete, such unspecified situations lead to errors in the collaboration. The user typically does not have a straight solution for this problem. This requires that a provider of customer support be informed, causing costs for maintenance. In some instances these costs can be small compared with losses in revenue or business that may result from the failure.
For humans it is a hard to achieve a fully consistent and complete collaboration specification. Only very experienced personnel will be capable of doing so. This is particularly true as the complexity of the collaboration specification grows dramatically with the number of messages that can be communicated. Even harder is it to achieve this goal of completeness of the process specification in a distributed team of developers, a case normal in today's world of software development. It is therefore highly desirable to provide a developer engaged in developing a specification for a collaborative process with a tool that supports him in achieving a complete and consistent process specification.